【登壇レポート】 『AWS Control TowerでセキュアでスケーラブルなAWS環境を作るとき 困るポイントn選』 JAWS FESTA 2023 in Kyusyu 直前スペシャル!! #jawsfesta2023

みなさん、こんにちは。

明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。

2023/9/30に開催されたJAWS FESTA 2023 in Kyusyu 直前スペシャル!!にて「AWS Control TowerでセキュアでスケーラブルなAWS環境を作るとき 困るポイントn選」というタイトルで登壇しました。

登壇資料のメイン箇所はアーキテクチャ図のみとなっているので、当日口頭で補足した箇所や参考になるブログなどのリンクをこの記事でフォローします。

登壇資料

概要と解説

前置き = 「生まれたままだと幼くて弱いControl Tower君を強くてマッチョに育成していこうぜ！！！！」

ここから本編です。

今回、Control Towerの設計構築・運用において困るポイント(ハマりどころ)として以下の6つ(+α)を挙げました。

• 組織のCloudTrailとメンバー側でのログ利用
• オプトインリージョンとガードレール
• IAM Identity Centerの委任管理者とアクセス許可セット
• IAM Identity Centerの外部IDソース指定
• リージョン拒否コントロール と Organizations統合のSecurity Hub
• Organizations統合したDetectiveとメンバーアカウント
• その他

それぞれのポイントについて解説していきます。

組織のCloudTrailとメンバー側でのログ利用

バージョン3.0以上のControl Towerのランディングゾーンでは、オプションとしてCloudTrailの組織の証跡を組み込むことができます。

オプションを有効化すると、以下が自動でプロビジョニングされます。

• CloudTrail(組織の証跡)の有効化
• CloudTrailログのログアーカイブアカウント配下S3バケット(aws-controltower-logs-[AWSアカウントID]-[リージョン名])への保管

アカウントごとのCloudTrailの有効化がOrganizations統合されたCloudTrailによって自動で管理されるため、便利なオプションです。

しかし、ログがControl Tower側で一括管理されてしまうため、メンバーアカウント利用者でログへのアクセスが実質できません（必須ガードレールでバケットポリシーの変更が禁止されています）

メンバーアカウント側でCloudTrailログを使えるようにするためには、別途CloudTrail証跡を新規で有効化して各自のS3バケットにログを保管することになります。

CloudTrailは基本的にAWS無料枠の範囲で利用できるサービスですが、アカウントごとに2つ以上の証跡を有効化すると追加コストが発生します。（参考: 料金 - AWS CloudTrail | AWS）

CloudTrailの組織の証跡によって各アカウントのCloudTrail無料枠が消費されるため、ログ利用を目的とした個別のCloudTrail有効化は2つ目の証跡の利用となってしまいます。

組織の証跡自体は便利な機能で、使った方がメリットがあると思います。個別のCloudTrailの有効化を回避する策としては、組織内へのSecurity Lakeの有効化およびサブスクライバーを使ったログへのセキュアなアクセス方法の提供が良いのではないかな、と感じます。¹

オプトインリージョンとガードレール

最近のControl Towerのアップデートで大阪リージョンをランディングゾーンの管理対象にできるようになりました。

ただ、2023年9月30日現在Control Towerでは大阪リージョンのような比較的新しいリージョンを「オプトインリージョン」と扱っており、一部のガードレールが利用できないことになっています。

大阪リージョンがランディングゾーンの管理対象のリージョンに含まれているとそれらのガードレールは有効化できず、利用できないガードレールが既に有効になっているランディングゾーンの管理対象に大阪リージョンを追加することも禁止されています。

詳しくは以下をご覧ください。

回避策は特にないため、大阪リージョンか一部のガードレールのどちらかの利用を諦めるか、アップデートを待つしかないと思われます。

IAM Identity Centerの委任管理者とアクセス許可セット

Control TowerやOrganizationsのベストプラクティスとして、「Organizations統合して利用するサービスについて、委任管理者を設定できるものは可能な限り設定し、管理アカウントの利用用途をなるべく減らす」というものがあります。

IAM Identity Centerも委任管理者を設定できるため、他のアカウントに委任することがベストプラクティスですが、画像にあるようなハマりどころがあります。

それは、管理アカウント上にIAMロールをデプロイした際に利用したアクセス許可セットは委任管理アカウントの権限で変更できなくなる、といったものです。

つまり、委任管理アカウントを使った運用を行うためには、管理アカウント用のアクセス許可セットと、委任管理者アカウント用のアクセス許可セットの少なくとも2種類が必要になるということです。

アクセス許可セットを使い回すような運用を想定している場合は注意しましょう。

使い回す運用がセキュリティ的にいいとは言えないので回避策は特にありません。準拠しましょう。

IAM Identity Centerの外部IDソース指定

Identity Centerのデフォルト設定では、SSOで使うユーザーやグループが「ローカルIDストア」と呼ばれるDBに保存され、AWSマネージドに管理されます。

ローカルIDストアに保存されるユーザー情報はいい感じにエクスポート&インポートできないため、SSOするユーザーグループを管理したい場合は外部IDソースを指定することになります。

外部IDソースとして、以下を指定できます。

• AWS上のActive Directoty(AD on EC2、Directory Serviceなど)
• オンプレミスのActive Directory
• Okta、OneloginなどのIDaaS

ただし、外部IDソースを指定した場合ローカルIDストアが利用できなくなり、かつローカルIDストアに保存されていたデータは削除されてしまうため、外部IDソースを接続しつつAWS側でもユーザーグループを作成できるようにしておく、なんていういいとこ取りはできません。

ID ソースを Active Directory に変更したり、Active Directory から変更したりすると、ユーザーとグループがアイデンティティセンターのディレクトリから削除されます。この変更により、IAM Identity Center で設定した割り当てもすべて削除されます。

参考: ID ソースを変更する - AWS IAM Identity Center (successor to AWS Single Sign-On)

限定的な回避策ですが、外部IDストアとしてオンプレミスのADを指定する場合、そのADをIdentity Centerと直接紐つけるのではなくAWS上のADリソース(MSADなど)を外部IDストアに指定してください。

AWS上のADとオンプレミスのADとの間に双方向の信頼関係を設定することで、AWS側でもユーザー管理ができるようになります。

リージョン拒否コントロール と Organizations統合のSecurity Hub

Control Towerのリージョン拒否コントロールを利用すると、ランディングゾーンの管理リージョン以外のAPIの実行を禁止できるようになります。

そのおかげで、通常は全リージョンに設定すべきCloudTrail、Config、GuardDuty、Security Hubなどセキュリティサービスを有効化するリージョンを少なくできます。

管理アカウントはランディングゾーンの管理対象ではありません。リージョン拒否コントロールも当然使えないため、個別にセキュリティサービスを全リージョン分実装する必要が出てきます。

GuardDutyなどの通知をリージョンまたぎで集約できるSecurity Hubを利用すると全アカウント全リージョンのセキュリティアラートを一括で管理できるのはご存知の通りです。

ただし、Organizations統合、委任管理者の設定とリージョン拒否コントロールが組み合わさると画像のように管理者アカウントで有効化したランディングゾーン管理下にないリージョンのアラートが集約できません。

これは委任管理者アカウント側でAPIの実行がリージョン拒否コントロールによってブロックされていることが原因だと考えられます。

回避策は以下のブログで紹介されているように、管理アカウントのSecurity HubをOrg統合の対象から外しアカウント個別に有効化することが考えられます。

Organizations統合したDetectiveとメンバーアカウント

Detectiveを使うとGuardDutyのアラート内容の詳細を分析できます。

Organizations統合でDetectiveを利用すると管理アカウントや委任管理アカウントでサービスが有効化されますが、メンバーアカウント側ではサービスは有効化されません。

それゆえ、管理アカウントたちからは自身のアカウントやメンバーアカウントのGuardDutyのアラートを分析できますが、メンバーアカウントは自身のアラート分析にアクセスできません。

DetectiveのOrganizations統合は、各アカウントへ分析のためのデータの収集が行われるのみで、サービスの有効化は含まれていないようです。

これらを回避するには、メンバーアカウントでサービスを利用するためにはメンバーアカウントでCLIなどを使って個別にサービスを有効化することになります。

ただ、Detectiveの利用料金は分析のためにサービスに取り込むデータ量で課金されるため、別個有効化してしまうと利用費が2倍かかるようになることが考えられます。

Amazon Detective は、AWS CloudTrail ログ、Amazon Virtual Private Cloud (Amazon VPC) Flow Logs、Amazon Elastic Kubernetes Service (Amazon EKS) 監査ログ、統合された AWS のサービスから AWS Security Hub に送信された検出結果、Amazon GuardDuty の検出結果から取り込まれるデータ量に応じて料金が設定されます。 アカウント/リージョン/月ごとに取り込んだギガバイト (GB) 単位で課金されます

結果、そこまでしてDetectiveを使いたいのかと悩んで個別に有効化しないという選択を取りがちです。

その他

アーキテクチャ図としては起こしませんでしたが、その他以下のような悩みもあります。

• IAM Identity Centerの許可セットの管理と最小権限の原則の徹底
• 検出のコントロールは Security Hub を使うべきか Control Tower 管理のセキュリティ基準を使うべきか？

前者はIAMの最小権限の原則に従ってIdentity Centerを実装すると、許可セットが無限に増えてしまう問題。

後者は検出ガードレールの実装のためにSecurity Hubを使うのか、最近のアップデートで追加されたControl Towerのサービスマネージド標準を使うのか、についてです。

登壇資料にトピックとして含めなかったのですが、個人的には「ランディングゾーンのアップデート対応にとても時間がかかる」という問題をなんとかしたいです。

現状ランディングゾーンのアップデートは、OU単位もしくはアカウント単位のシリアルなアップデートのみしかできないため、アップデートのオペレーションに時間がかかりまくります。

複数OU、複数アカウント並行してアップデートできたり、いい感じに組織全体のアカウントのランディングゾーンのアップデートができる機能を求めています。

最後に

マルチアカウント管理をこれから始める方、既に開始していて色々ハマっている方にとって参考になれば幸いです。

タイトルにあるn選の答えは6選でした。

以上、芦沢(＠ashi_ssan)でした。